⚠️ 주의
해당 포스팅은 우아한 테크코스의 강의내용에 대한 작성자의 이해를 바탕으로 작성된 글입니다.
프로그래밍에 정답은 없습니다. DDD가 옳은 것 만은 아니며, 작성자 역시 배워가는 과정이기 때문에 본문에 부정확한 정보가 포함되어 있을 수 있으니 주의 바랍니다.
기존의 개발 방식이 가지고 있던 문제
예제
다음과 같은 개발 과정을 생각해봅시다.
- 기획자와 심도 있는 논의를 거쳐 기획이 결정된다.(또는 기획자가 일방적으로 결정한다.)
- 기획서를 보고 데이터베이스 테이블을 설계한다.
- 데이터베이스 테이블을 기반으로 모델을 만든다.
- getter와 setter 메서드가 모델에 추가된다.
- 서비스가 매우 커진다.
현실에서는 기획이 개발 도중에 계속 변경되기도 합니다.
새로운 기획이 추가된 상황을 생각해봅시다.
- 기획자와 심도 있는 논의를 거쳐 기획이 결정된다.(또는 기획자가 일방적으로 결정한다.)
- 기획서를 보니 데이터를 중복으로 관리하기보다는 기존 테이블에 새로운 컬럼 몇 개만 추가하면 될 것 같다.
- 새로운 getter와 setter 메서드가 모델에 추가된다.
- 서비스가 매우 커진다.
이런 문제가 발생하는 원인은 무엇일까요?
이 상황에서는 데이터베이스 테이블에 초점을 맞춰 모델을 설계했기 때문입니다.
그럼 우리는 소프트웨어를 설계할 때 무엇에 집중해야 할까요?
소프트웨어의 존재 가치
잠시 소프트웨어의 존재 가치에 대해 논해봅시다.
우리는 왜 소프트웨어를 만드는 걸까요?
소프트웨어의 본질은 바로 문제를 해결하는 것에 있습니다.
아무리 기술적으로 정교하고 뛰어난 성능을 갖추고 있더라도, 정작 당면한 문제를 해결할 수 없다면 실패한 소프트웨어라고 할 수 있습니다.
앞서 던졌던 질문을 다시 가져오겠습니다.
우리는 소프트웨어를 설계할 때 무엇에 초점을 맞춰야 할까요?
여기서 소프트웨어가 해결하고자 하는 문제에 초점을 맞추어 소프트웨어를 설계하는 방법론이 바로 제가 이해한 DDD의 핵심입니다.
소프트웨어 복잡성
프레데릭 브룩스의 정의에 의하면, 어플리케이션은 크게 2가지 부류의 복잡성(Complexity)을 가지고 있습니다.
- 본질적 복잡성 : 어플리케이션이 해결해야하는 본질적 문제에 따른 복잡성 - 도메인
- 우발적 복잡성 : 어플리케이션 개발을 위해 사용하는 도구(솔루션)에 따른 복잡성 - 언어, 기술, 도구
이해하기 쉽게 설명하자면 우리가 소프트웨어 개발 과정에서 겪는 모든 문제는 소프트웨어가 가지고 있는 복잡성으로 인한 것이라고 할 수 있습니다. 그 중에서도 소프트웨어가 해결하고자 하는 문제, 즉 요구사항이 복잡하기 때문에 소프트웨어가 복잡해지는 것이 바로 본질적 복잡성이며 이 요구사항을 해결하는 과정에서 예상치 못하게 맞닥뜨리는 문제들을 우발적 복잡성이라고 합니다.
앞서 제시했던 예시 시나리오에서 문제가 발생한 이유도, 우발적 복잡성에 해당하는 데이터베이스에 집중했기 때문이었죠. 소프트웨어를 만들기 위해서는 본질적 복잡성과 우발적 복잡성을 구분하고, 본질적 복잡성을 해결하는 데 초점을 맞추는 것이 중요합니다.
따라서 우리는 본질적 복잡성, 즉 도메인에 집중하여 소프트웨어를 설계해야 합니다.
도메인 주도 설계(DDD)
도메인이란?
도메인이란 소프트웨어로 해결하고자 하는 문제 영역이다.
도메인은 사용자가 소프트웨어를 사용하는 대상 분야를 의미합니다. 복잡성의 관점에서 서술하자면 도메인은 본질적 복잡성에 해당하는 '문제'의 범위입니다. 도메인은 소프트웨어 사용자의 활동 또는 관심사와 관련되어 있습니다.
이해를 돕기 위해 예시를 들어보겠습니다.
병원에서는 모든 환자의 진료 기록을 보관하고 분석하기 위해 소프트웨어를 사용하고, 은행에서는 소중한 자산을 관리하고 보호하기 위해 소프트웨어를 사용합니다.
소프트웨어의 사용자들은 이처럼 자신이 관심을 가지고 있는 특정 분야의 문제를 해결하기 위해 소프트웨어를 사용합니다.
도메인 모델이란?
모델이란 현실 세계에 있는 것 중 우리에게 필요한 부분만 따와 단순화하고 의식적으로 구조화한 형태를 의미합니다. 간단히 말해서 대상을 단순화해서 표현한 것입니다.
도메인 모델이란 사용자가 프로그램을 사용하는 대상 영역(=도메인)에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태를 일컫습니다. 항공권 예약 시스템에서는 항공기, 승객 등 물리적으로 존재하는 것들을 모델링할 수 있고, 회계 시스템에서는 화폐, 금융, 이자 등 물리적으로 존재하지 않는 것들도 모델링할 수 있습니다.
도메인 모델을 사용하면 기획자, 디자이너, 마케터, 고객 등 소프트웨어 개발과 관련된 이해관계자들이 동일한 모습으로 도메인을 이해하고 소통하는 데 도움이 됩니다. 이러한 의미에서 도메인 모델은 이해관계자들이 도메인에 대해 생각하는 관점이자, 의사소통의 수단입니다.
도메인 주도 설계
앞서 도메인 모델은 의사소통을 위한 수단으로서 기능한다고 언급했었습니다. 실제로 도메인 주도 설계가 등장하게 된 배경도 이해관계자들과의 소통을 쉽게 하기 위해서였습니다. 옛날에는 고객과 개발자가 서로 생각하고 있는 용어(모델)가 달라 의사소통에 어려움이 있었고, 이를 공통된 도메인 용어를 사용하는 것으로 해결하고자 한 것입니다.
도메인 주도 설계는 도메인 모델의 적용범위를 문제의 개념적 추상화에서 나아가 구현으로까지 확장하기 위한 원칙, 패턴을 제공하고 있습니다.
소프트웨어 모델링하기
Bounded Context
한 번에 소프트웨어를 구현하기에 도메인은 너무 큽니다. 그래서 우리는 도메인 내의 관심사를 분리하고 격리하여 문제해결에 집중할 범위를 결정해야 합니다. 예를 들면, '이커머스'라는 도메인은 주문, 결제, 정산, 상품과 같은 하위 도메인으로 나눌 수 있습니다. 이 중에서도 우리의 문제해결에 필요한 도메인들에만 집중하자는 것이죠.
하위 도메인마다 같은 용어라도 의미가 다르고, 같은 대상이라도 지칭하는 용어가 다를 수 있습니다.
예를 들면, 회원이라는 하위 도메인이 존재한다고 해봅시다.
고객 지원 서비스에서는 고객의 생일마다 할인 쿠폰을 보내주는데요. 이 경우 회원 도메인이 '생일' 정보를 가지고 있는 것은 자연습니다.
반면 판매 서비스에서는 회원의 생일은 불필요한 정보입니다. 해당 분야에서는 회원의 생일보다는 회원이 어떤 상품을 몇개나 구매하려는 것인지가 주된 관심사일 것입니다.
관심사를 분리한다는 것은 이런 의미입니다.
따라서 한 개의 모델만으로 모든 하위 도메인을 표현하려 해서는 안됩니다. 모델은 특정한 컨텍스트(맥락) 하에서 완전한 의미를 갖기 때문에, 올바른 도메인 모델을 개발하기 위해서는 도메인 모델마다 하위 도메인을 만들어야 합니다.
이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서 Bounded Context라고 칭합니다.
도메인이 문제의 영역을 의미한다면 Context는 해결의 영역입니다. 각각의 Bounded Context는 각각의 개발 환경을 가질 수 있습니다.(실무에서 팀을 나누는 기준이 되기도 함)
유비쿼터스 언어
DDD 관점에서의 모델링에서 중요한 다른 한가지 특징은 바로 유비쿼터스 언어입니다. 도메인에서 실제 사용되는 용어를 코드에 반영하지 않으면 개발자는 그 코드의 의미를 해석해야 하는 부담을 지게 됩니다. 용어가 정의될 때마다 용어 사전에 이를 기록하고 명확하게 정의함으로써, 추후 다른 사람들도 공통된 용어를 사용할 수 있도록 해야 합니다.
즉, 언제 어디서든 사용될 수 있는 통용된 용어를 사용하는 것이 좋습니다.
마무리
이번 포스팅에서는 DDD가 등장하게 된 계기와 DDD를 이해하기 위한 중요 개념들에 대해 정리해보았습니다. 다음 포스팅에서는 실제 DDD를 기반으로 소프트웨어를 설계하는 원칙들에 대해 알아보도록 하겠습니다.
참고 자료
우아한테크코스 제이슨 코치의 강의 내용
도서 [객체 지향의 사실과 오해]